The Debian Python Modules Team is discussing which DVCS to switch to from SVN. Ondrej Certik asked how to generate a list of commiters to the team s repository, so I looked at it and got this:
emilio@saturno:~/deb/python-modules$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
865 piotr
609 morph
598 kov
532 bzed
388 pox
302 arnau
253 certik
216 shlomme
212 malex
175 hertzog
140 nslater
130 kobold
123 nijel
121 kitterma
106 bernat
99 kibi
87 varun
83 stratus
81 nobse
81 netzwurm
78 azatoth
76 mca
73 dottedmag
70 jluebbe
68 zack
68 cgalisteo
61 speijnik
61 odd_bloke
60 rganesan
55 kumanna
52 werner
50 haas
48 mejo
45 ucko
43 pabs
42 stew
42 luciano
41 mithrandi
40 wardi
36 gudjon
35 jandd
34 smcv
34 brettp
32 jenner
31 davidvilla
31 aurel32
30 rousseau
30 mtaylor
28 thomasbl
26 lool
25 gaspa
25 ffm
24 adn
22 jmalonzo
21 santiago
21 appaji
18 goedson
17 toadstool
17 sto
17 awen
16 mlizaur
16 akumar
15 nacho
14 smr
14 hanska
13 tviehmann
13 norsetto
13 mbaldessari
12 stone
12 sharky
11 rainct
11 fabrizio
10 lash
9 rodrigogc
9 pcc
9 miriam
9 madduck
9 ftlerror
8 pere
8 crschmidt
7 ncommander
7 myon
7 abuss
6 jwilk
6 bdrung
6 atehwa
5 kcoyner
5 catlee
5 andyp
4 vt
4 ross
4 osrevolution
4 lamby
4 baby
3 sez
3 joss
3 geole
2 rustybear
2 edmonds
2 astraw
2 ana
1 twerner
1 tincho
1 pochu
1 danderson
As it s likely that the Python Applications Packaging Team will switch too to the same DVCS at the same time, here are the numbers for its repo:

emilio@saturno:~/deb/python-apps$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
401 nijel
288 piotr
235 gothicx
159 pochu
76 nslater
69 kumanna
68 rainct
66 gilir
63 certik
52 vdanjean
52 bzed
46 dottedmag
41 stani
39 varun
37 kitterma
36 morph
35 odd_bloke
29 pcc
29 gudjon
28 appaji
25 thomasbl
24 arnau
20 sc
20 andyp
18 jalet
15 gerardo
14 eike
14 ana
13 dfiloni
11 tklauser
10 ryanakca
10 nxvl
10 akumar
8 sez
8 baby
6 catlee
4 osrevolution
4 cody-somerville
2 mithrandi
2 cjsmo
1 nenolod
1 ffm
Here I m the 4th most committer And while I was on it, I thought I could do the same for the GNOME and GStreamer teams:
emilio@saturno:~/deb/pkg-gnome$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
5357 lool
2701 joss
1633 slomo
1164 kov
825 seb128
622 jordi
621 jdassen
574 manphiz
335 sjoerd
298 mlang
296 netsnipe
291 grm
255 ross
236 ari
203 pochu
198 ondrej
190 he
180 kilian
176 alanbach
170 ftlerror
148 nobse
112 marco
87 jak
84 samm
78 rfrancoise
75 oysteigi
73 jsogo
65 svena
65 otavio
55 duck
54 jcurbo
53 zorglub
53 rtp
49 wasabi
49 giskard
42 tagoh
42 kartikm
40 gpastore
34 brad
32 robtaylor
31 xaiki
30 stratus
30 daf
26 johannes
24 sander-m
21 kk
19 bubulle
16 arnau
15 dodji
12 mbanck
11 ruoso
11 fpeters
11 dedu
11 christine
10 cpm
7 ember
7 drew
7 debotux
6 tico
6 emil
6 bradsmith
5 robster
5 carlosliu
4 rotty
4 diegoe
3 biebl
2 thibaut
2 ejad
1 naoliv
1 huats
1 gilir

emilio@saturno:~/deb/pkg-gstreamer$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
891 lool
840 slomo
99 pnormand
69 sjoerd
27 seb128
21 manphiz
8 he
7 aquette
4 elmarco
1 fabian
Conclusions:
- Why do I have the full python-modules and pkg-gstreamer trees, if I have just one commit to DPMT, and don t even have commit access to the GStreamer team?
- If you don t want to seem like you have done less commits than you have actually done, don t change your alioth name when you become a DD (hint: pox-guest and piotr in python-modules are the same person)
- If the switch to a new VCS was based on a vote where you have one vote per commit, the top 3 commiters in pkg-gnome could win the vote if they chosed the same! For python-apps it s the 4 top commiters, and the 7 ones for python-modules. pkg-gstreamer is a bit special

Soon after Bernd Zeimetz joined our company, he infected me with the geocaching virus. In the meantime, I bought a GPS receiver, and am now endeavoring around the town and the nearby woods, searching for caches. There's not that much free GPS and/or geocaching software around. gpsd works quite well, but I don't take my computer to the woods ;) Viking is very nice for visualizing waypoints and sorting them in categories, but is still somewhere between alpha and beta state. gpsbabel reads and writes a zillion different file format and talks to a vast array of receivers, but often needs several attempts to upload data to mine. Things are moving fast though and the GPS community looks active. Last week I started looking into OpenStreetMap and already added a few roads in my neighborhood. Compared to commercial maps, there's still much to do, especially for smaller tracks and features like foot bridges or woods outside bigger cities. I'll keep collecting GPS data :) For the free software side, neither OSM's online editor worked here (flash), nor the recommended tool for local use (java), so I tried merkaartor (qt4) which works nicely. It also has some bugs, but feels very usable (though sometimes slow). Starting from upstream's debian/ dir, building packages was straightforward, and after some more editing, packages are now in unstable. (The svn repository is in collab-maint, contributors welcome.)

svn-uscan Might be useful if you use svn-buildpackage and co-maintain packages or have to sponsor/review them:

0 bzed@hal:~$ type svn-uscan
svn-uscan is aliased to  uscan --verbose --force-download --rename --repack --destdir=../tarballs'
0 bzed@hal:~$

python-application … is what I'm in love with since a few days. Although I had no real use for it when I packaged it, I'm more than happy to have it now. It comes with the following features:

• UNIX process management (forking, signal handling, pid file creation)
• A very simple to use interface to handle configuration files.
• An extensible system logger for console and/or syslog.
• Miscellaneous utilities and helpers.
• Memory troubleshooting and execution timing.

Have a look at the examples in /usr/share/doc/python-application/examples to see how simple common things become if you use python-application for them, or just read trough the code, it's well commented and easy to understand.

mod_wsgi 1.2 + 2.0~c1 We had two mod_wsgi uploads a few days ago:

• 1.2 to unstable, bugfix release which is supposed to go to http://backports.org after migrating to testing.
• 2.0~c1 to experimental - if you're not running mod_wsgi in a critical environment, please give this 2.0 beta a try and report bugs and problems. It comes with several new features, so you want to read the change log I've linked to the version number.

short package update Didn't find the time to blog lately, so here's the very short summary of (hopefully) all news regarding the more important packages I take care of: gimp-plugin-registry / gimp-refocus gimp-plugin-registry is at version 0.4.2-1 now, including several updates and new plugins since my last blog entry. Also I've moved the refocus plugin into gimp-plugin-registry - now gimp-refocus is only a transitional package, which will install gimp-plugin-registry. gimp-refocus will be removed from Debian before Lenny will be frozen. As it was not shipped with Etch there's no need keep the transitional package in the release. gpsd Successfully hijacked gpsd, the new upload fixed a lot of bugs, including one old RC bug which was the reason why gpsd was removed form testing. If you're using gpsd please check the packages in unstable - comments appreciated. If you've used libgps form the gpsd package before, you'll have to look into the libgps-dev and libgps16 packages now. Bugs against packages using the library were filed in time. Also I plan to get a beta version of 2.35 into experimental during the next weeks, which will come with a more or less completely rewritten NMEA layer and a lot of fixes and improvements. radiance Finally integrated in Debian! Development of radiance started in 1985 and is still actively developed, but nobody every thought about including it in Debian. I'll blog about radiance later, in the meantime please read this wikipedia article. viking Today the latest version 0.9.3 was uploaded to unstable. Most important addition: Realtime GPS tracking, using gpsd. If you're interested in OpenStreetMap, geocaching or any other fun with GPS devices, take a look into viking.

Bernd blogged about the new version of gimp-plugin-registry he packaged, which includes the cool new GIMP Liquid rescale plug-in which I had to try out. It really rocks, though it is much slower than in that video.

Anyway, backports for etch are available at "deb http://layer-acht.org/debian etch backports" Those are simple rebuilds of gimp-plugin-registry and opencv.

If you replace backports with xorg or xorg-experimental you'll also find rebuilds of xorg for etch, either from lenny or from experimental. They are slightly outdated (built two weeks ago) and need to updated against the newer sources, but they work for me.

gimp-plugin-registry 0.3.1-1 Some hours ago the new 0.3.1-1 version of my gimp-plugin-registry package was uploaded to unstable. Thanks to Ari Pollak - not only for sponsoring the upload, but also for asking me to include the GIMP Liquid rescale plug-in, which is one of the most amazing plugins I've ever seen for The GIMP. If you have no clue what 'liquid rescaling' means, here's a YouTube video for you (if anybody finds a non-flash version of that video in the net - please let me know and I'll link it): (http://www.youtube.com/watch?v=6NcIJXTlugc) And again, if you'd like to see a plugin included, please let me know.

winpdb - a platform independent Python debugger A few minutes ago a mail arrived which told me, that my winpdb package migrated to testing, which was just another reminder to blog about it. winpdb is not just yet another Python debugger, it is actually the first really well working one I've used so far. One of my favorite features is the embedded debugging, which allows you to debug scripts which are embedded somewhere. I still have to try it with a Zope product, though - I'm really wondering if I could embed the remote debugger in there. That just brought us to another very useful feature - winpdb is a remote debugger. It connects to the real debugger (called rpdb2) using an encrypted and password protected tcp connection, which allows you to run rpdb2 under a totally different user, probably on some embedded box somewhere on the other side of the world. If you don't want to use a graphical frontend, rpdb2 is able to run the debug sessions in a 'screen' window. Although winpdb doesn't ship much documentation, it is very well documented. And in case you don't like winpdb or wx - pida ships with a debugger plugin which is in fact a gtk frontend for rpdb2. The following quote is part of a mail from Nir Aides, the author of winpdb. Although it may be biased, I think it'll probably give you some ideas in case you want to compare winpdb with some other common (commercial) debuggers. He kindly allowed me to quote it here:

I have just spent a couple of hours (instead of doing some real work…) with the commercial Python debuggers of Komodo IDE 4.1 and Wing IDE 3 beta, and (without declaring objectiveness) Winpdb seems currently better than both in several important areas:

* It is the only one of the three to support os.fork() (wingide debugger crashes)

* It handles thread debugging best in many aspects (e.g allows inspection of threads that are still running, stays with the correct thread when stepping, general usability, etc…)

* Its name-space browser is the most consistent and stable (in particular with describing class inheritance, very large objects, sets!)

* It is the only one that prevents breakpoints in invalid lines (Komodo does not care at all and Wing allows setting breakpoints inside remarks and thus possibly in other invalid lines). This is important since in Python it is sometimes surprisingly hard to tell (by looking at the source code) which lines are valid for breakpoints.

Not to forget that winpdb supports debugging of curses based applications, namespace modification and the coming version is supposed to have full unicode support. Happy debugging!

mod_wsgi 1.0 Yesterday the official 1.0 version of mod_wsgi was released and uploaded to unstable (the binary package you want to install is called libapache2-mod-wsgi, in case you were wondering), so I think it's a good time to blog about it. Mod_wsgi is an Apache module which can host any Python application which supports the WSGI interface (the reference is also available as package). Major applications and frameworks which are known to work well with mod_wsgi include CherryPy, Django, Karrigell, Pylons, TurboGears, web.py, MoinMoin, PyBlosxom and Trac. In fact every application which provides a WSGI compatible interface should be able to be hosted with mod_wsgi. The module is very simple to use, is very well configurable, documented, has a very active and responsive upstream author and is suitable for use in hosting high performance production web sites, as well as your average personal site. There are two common ways of operation:

• Embedded mode - working in a way similar to mod-python: The Python code is executed within the context of the Apache child process.
• Daemon mode - similar to FASTCGI/SCGI solutions, but with the important difference that a separate infrastructure is not needed when implementing the WSGI application and everything is handled automatically by mod_wsgi. Of course this mode has a smaller impact on the normal Apache child processes and also allows to run applications under different users.

If you're running python web applications which provide a WSGI interface: go and give mod_wsgi a try! ~~DISCUSSION~~

debconf7 flashback Somehow I didn't find the time to blog during the last weeks, so there's a lot of stuff on my blog todo list. But let's start with a little flashback , back to Debconf7 in Edinburgh. Yesterday I got a film back from the lab with photos I've taken during the daytrip-day. As a few of you probably realized I was not on the train/boat to the island in the west, mainly because Andreas (afit), Julian (codemonk) and me decided to spend the day in Ediburgh, not only for some geocaching fun but also to see a bit more of this beautiful town and area. We've also been up on Arthur's Seat, Edinburgh, where I took this panorama: It will be published on placesofinterest.info, which is currently in public beta state, but definitely worth a look (just don't use IE, but I doubt you use non-free software, right?). I'll blog more about placesofinterest.info as soon as the page is finished. As usual, the pano was created with the help of The Gimp, hugin and enblend. The only commercial software involved was the software for the Imacon scanner at university. Original resolution: 24044×2551 pixel, stitched from 14 slides. If anybody is interested - large format prints for Debconf participants are available for the cost of paper and ink.

gimp-plugin-registry updated During the last days I've upgraded the gimp-plugin-registry package. Version 0.2-1 does not only fix a few smaller bugs, but also contains the following new plugins/scripts:

• Black and White Film Simulation:
  Converts the selected layer into Black and White using the channel mixer. Tries to produce results resembling tonal qualities of film.
• DBP:
  David's Batch Processor is a simple batch processing plugin for The Gimp - it allows the user to automatically perform operations (such as resize) on a collection of image files.
• Extended Borders:
  This script allows you to add double borders, add copyright notice and title, as well as decide fonts, font-sizes and positions of the title and copyright notice. Support for blurring the copyright and title is also included.

Please note that not all plugins will work with gimp 2.3 from experimental, therefore my next plan is to create a branch for experimental, which will not only include the proper changes for 2.3, but also include plugins which need the new gimp version to build/work. For example:

• Save for web
• Separate+

As usual, I'm searching for good plugins which should be added to the package - suggestions are welcome!

First Draft of the Vim Packaging Policy Available Yay again for DebConf7!! Today the talks I attended were really interesting and in the remaining slices of time I managed to complete ... suspense ... the first draft of the Vim packaging policy \o/. The policy covers packaging of Vim addons and start to tell people about vim-addon-manager. The policy will be shipped in the next upload of the Vim package and is also available on the web. If you're maintaining a package which ships an extension for Vim please have a look, since soon it will be enforced on your package Also an eye from native English speakers will be appreciated, no matter if you speak Vim or not. PS please do not tell bzed about that, he will probably be hating me for "wasting" time on Vim rather then on polishing the first Zenoss package ever

hacking at debconf Zenoss Stefano reported about the work on the Zenoss packages yesterday, now I m proud to be able to present the first screenshot from Zenoss, freshly installed by using dpkg -i. There s still a lot of work waiting for Fabio, Stefano and me, but it s great to see the first results. It s really great to work together with them, here on the Debconf. I m really happy that I can be here. At the moment we re waiting for Sean Finney no arrive, as we have some questions about dbconfig-common. hacklab pano 3 Again, here s another pano from the hacklab 1, taken yesterday evening. Sorry for the bad stitching, didn t have the time to fix it, but I hope it ll still give am impression of the great atmosphere here in the Teviot.

debcamp hacklab Although we ve moved into a different room a few minutes ago, here s a little pano from yesterday, thanks to tokkee s cam, hugin, autopano-sift and gimp Update: Here s another hackish pano of one of the hacklabs we re using since today. The stitching is not perfect again, I ll probably fix this when I m home again - or not

gimp-plugin-registry Dear lazyweb, since a few days there s gimp-plugin-registry waiting in unstable. At the moment the package contains several tiny GIMP plugins I like to use and which are not included in the gimp package or in other gimp-* packages. In my opinion a collection like this one was missing in Debian, since there re a lot of very nice plugins/scripts out there, which are too small to package them on their own.
Which plugins would you like to see in the collection? Packaging all plugins from http://registry.gimp.org/ doesn t make sense, so I d like to know which plugins other people are using and put them into the next release of the package. Any feedback is appreciated. P.S.: As I didn t find a real alternative for my needs, I ll stay with Dokuwiki. As far as I remember is a rss feed with proper html on Andi s todo list, and there re more other nice features going to come Although somehow I still would like to rewrite Dokuwiki in python

hi, planet && iso8859-15 to utf8 with netatalk magic Hi, Planet!
Welcome to my blog, and thanks to Martin for subscribing me. I m not going to bother you with any details about me, if you have any questions feel free to ask me on freenode or oftc (in case you re wondering: my nick is bzed).

After a longer time of planning we ve upgraded our main file server at work: New machine, new storage (7TB - woohoo!), Etch instead of Sarge and UTF-8 for file names instead of ISO8859-15. Everything not a too complicated thing, except for renaming the about 10,000,000 files from ISO8859-15 to UTF-8 in a proper way.
In theory this is easy, as convmv happily takes care of the problem. But this did not work for us unfortunately, as we re not only providing NFS and Samba services, but also AFP (Apple_Filing_Protocol) via netatalk. Years ago you had to choose ISO8859-15 if you wanted to allow your Apple and Windows users to see the same, non-broken file names - not only because AFP didn t support UTF8 before version 3, which came out with OSX1). Normally you d think that a server would not allow a client to write a file with a file name which includes not supported characters - again, OSX and netatalk go their own way here:
Characters which are not supported by the underlying file system are character(!)-wise encoded using the CAP encoding. So we had to find a way to

• convert file names from ISO8859-15 to UTF-8
• replace CAP encoded characters by the appropriate UTF-8 character

Luckily netatalk ships the uniconv(1) util2) which is able to take care of this problem. It also updates the CNID3) Database at the same time. There s two things you need to take care of in case you re using the dbd CNID backend:

• uniconv assumes that cnid_metad is listening on port 4700, you need to start it first. Don t run afpd at the same time!
• If you ve specified external CNID dbpaths in your AppleVolumes.default (normally they re located in the root of each volume, prone to be deleted by users accidentally), you need to move the .AppleDB directory into your volume s root directory, otherwise uniconv will create a new CNID database. Just move it back as soon as uniconv is finished.

Be careful: uniconv assumes that all colons in a file name are part of a CAP encoded character. That s not a problem as long as you have only Mac and Windows clients accessing your server, as both systems do not allow colons in file names. In our case we found a number of cache files from Nautilus (which is running on our sunray/Solaris web-surf terminals as default browser) with colons in the file name. I hope no user will miss them Including a final synchronisation of all files to the new storage, about two hours it took uniconv to convert the file names and a aunch break, we were finished after about 14 hours of work. Until now it seems that our users didn t notice the change at all, except for those who realized that they have much more free space now. Looks like a successful weekend so far! 1) and uses a NFD variant of Unicode normalization (UTF-8#Mac_OS_X), but netatalk takes care of this and translates it into the NFC form, which is used on most other platforms 2) it s called netatalk-uniconv in Debian and shipped with netatalk 3) Catalog Node ID, another crust from old Mac OS versions

Bernd Zeimetz wanted to play Lotto using the famous crypto key that was used a processing key for most HD-DVDs so far. But he ran into the problem that the key (which is usually represented in hex) uses 256 numbers, lotto only has 1-49.Well, remember that in fact the key is a single number. So why process it as hex digits which is very artificial?

def lotto(x, y):
  if x = 0: return y
  return lotto(x / 49, [int(x%49+1)] + y)

lotto(0x09F911029D74E35BD84156C5635688C0, []) Here's your list of lotto numbers:

[43, 25, 5, 27, 12, 13, 44, 45, 1, 6, 10, 1, 20, 30, 2, 44, 5, 20, 18, 11, 6, 34]

Base 49 representation (lower digits last, shifted by 1) of the key. If you need more digits, add leading 1s. (which is the same as adding leading zeros to a decimal number).

playing german lotto update: sorry for the broken feed, I hope I ve kicked this piece of php hard enough so it works as it s supposed to work. Tomorrow I ll replace it by something maintainable, written in python. Stefano, I have no clue how the lottery in Italy works, but I ll play the numbers generated by this little program on Wednesday and Saturday:

#!/usr/bin/python
 
numbers = ["09", "F9", "11", "02", "9D", "74", "E3", "5B",
           "D8", "41", "56", "C5", "63", "56", "88", "C0"]
 
#in germany all lotto numbers x must be 1 <= x <= 49
numbers_int = [ (int(num, 16) % 49) + 1 for num in numbers ]
 
#unfortunately 16 numbers are not enough for 3 fields in
#the german lottery, so let's add the current year
#(of course, you can add 2 other numbers, if you don't like this year)
numbers_int += [20, 07]
 
print "your numbers for the german lotto:"
print numbers_int[0:6], numbers_int[6:12], numbers_int[12:18]